Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP21。

安全管控識別與優先性

普遍常見的安全控制措施分類：

1. Physical Controls (實體物質的安全管控措施)
2. Administrative Controls (流程管理與安全意識訓練措施)
3. Technical Controls (使用者身分識別或邏輯存取措施管控)

Architecture Disscuss Part1

在繼續討論安全開發的議題前，一定要了解到非功能性的安全機制與約束，這樣在定義相關的安全威脅時可以更加得清楚與明朗。

尤其是現今整體的軟體運算環境已不再像過去全仰賴集中化運算，架構則局限於單一的 client-server 架構，可能有更多不同種類與形式的運算設計架構，採用這些不同的運算設計架構，就會有各種不同的非功能性的安全機制與約束。

在 OWASP SAMM 的 Security Architecture 也提到相關架構的安全性觀點不同，會影響著軟體設計的安全性措施。

因此，來了解一下當今可能運用到的軟體運算的架構環境。

Distributed Computing (分散式運算)

分散式運算對比集中式運算的好處：

• 價性比高
• 可以有更多的運算能量
• 可以隨著商業規模增加逐步增加運算能量

大致上可分成：

• 3-Tier 架構 - 觀念上的設計架構通常會衍伸為 N-Tier。
• N-Tier 架構 - 絕大部分 Web 應用在實務運用的設計架構。
• Peer-to-Peer 架構 - 檔案分享與 IM (Instant Message)應用。

3(or N)-Tier 架構

在各個 Tier 去設置其安全管控，若以 Web 應用在 OWASP 於 2005 年時撰寫的文獻 就整理出了每個 Tier 可能會面臨的威脅：

• Web Tier -

  • Poor Session Management
  • Parameter Manipulation
  • Path Traversal and Path Disclosure
  • Canonicalization (正規化/標準化問題)
  • URL Encoding
    ...etc

• Logic Tier -

  • Broken Access Control
  • Input Validation Problems
    • Buffer Overflow
    • Cross Site Scripting (XSS)
    • SQL Injection
    • Command Injection
  • Insecure Exception Management
  • Insecure User of Cryptography
  • Insecure Default Congfiguration
  • Insecure Auditing and Logging
    ...etc

• Persistence Tier -

  • Insecure Storage
    ...etc

上圖取自 Securing Enterprise
Web Applications at
the Source: An
Application Security
Perspective Perspective 第 14 頁 Figure 1

時至今日，可列出更多威脅絕對是只有更多沒有變少，但對於任何威脅都要隨時保持著 C.I.A & A.A.A 兩大概念去面對。

Peer-to-Peer 架構

是在整個網絡運算架構上不需仰賴某台機器的運算，取而代之的是統籌運用網路連線點的運算，並且每個節點既是 Server 也是 Client，且每個運算節點也都是同等地位的，但是由於 P2P 很常廣泛的運用在 File Sharing 的運算情境，但 File 的偽冒(惡意程式)也是壞蛋們(EP16-APT)很喜歡用來的使壞手段，EX: CAPEC-23 : File Content Injection、CAPEC-165 : File Manipulation、CAPEC-497 : File Discovery...等。

因此當使用 P2P 架構時，一定要對於傳入的資料有防控的安全機制，並且保持不信任其連線中資料來源端的資料進行運作。

Message Queuing (訊息駐列)

無論是在分散式網路架構當中的哪種運算模式，必然可能會使用非同步通訊模式、網路意外中斷時進行資料的暫存，為求資料的順序性的正確時會使用到 Queuing 來處理。

Service-Oriented Architecture (SOA)

SOA: 將商業邏輯應用進行服務化運作。

在對企業內部透過 Enterprise Service Bus (ESB) 處理；對企業外部透過 Web Service (SOAP/RESTFull)運作；可獨立特殊應用化則透過 Microservice 進行。

Secure Web Services

在 OWASP API Security Project 當中也開宗明義地說：

By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers.

因此也有列出 "API Security Top 10 2019"：

• API1 :2019 Broken Object Level Authorization
• API2 :2019 Broken User Authentication
• API3 :2019 Excessive Data Exposure
• API4 :2019 Lack of Resources & Rate Limiting
• API5 :2019 Broken Function Level Authorization
• API6 :2019 Mass Assignment
• API7 :2019 Security Misconfiguration
• API8 :2019 Injection
• API9 :2019 Improper Assets Management
• API10:2019 Insufficient Logging & Monitoring

從上述的 Top 10 可觀察到其多為探討在 API 當中要進行的 "驗證" 與 "授權" 問題，而兩者之間授權問題更是比驗證問題更為重要。

Rich Internet Application (Web 網頁應用效果桌面化: RIA)

RIA: 透過一定的執行環境並下載所需的執行檔，在瀏覽器的沙箱機運作的 Web 應用。

過去曾經輝煌過的 Flash、Java Applet、JavaFX、Sliverlight...等技術，以及目前正在興起的 WebAssembly 技術。而 HTML5 搭配各個潮到出水的 Web 前端技術，可能不太算 RIA。

其中若遭遇在傳輸過程中的安全保護機制被 Browser 給刻意/惡意忽略掉時，則可能會造成其安全威脅。

而由於 RIA 也允許使用時其網路的間歇性的中斷，或離線時的運算，也可能造從資料的更多額外的洩漏威脅發生。

Pervasive and Ubiquitous Computing 普及運算

常見的名詞有 IoT、RFID、NFC、Sensor Networks，都算是這類觀點，其運算的特性不像過去的傳統電腦裝置，有其大量運算能力與泛用的運算能力。

而其因運算力較低且有足夠的 "數量"，無法進行應有的安全驗證、授權與資料保護，而導致被劫持後進行 DoS 的威脅，或資料的安全性保護措施無法到位，造成資料或隱私資訊外洩。